All I wanted to do was get the appropriate parameters of a filtered dataset. In order to properly display a filter's properties, we need to look up that processor that produced it. get_own_processor? Not here.

DataSet.type == BasicProcessor.type is True 99% of the time. But a DataSet's type represents the result file and how it is structured (e.g. extension, map_item, etc.). Filters, merge dataset, and a couple other places are processors that manage to create a dataset of a different type then themselves.

This goes about codifying this slight difference by an adopt_type method that allows a DataSet's type to be changed while also recording a producer_type parameter. We could also fold in any other necessities here if needed. I block setting type directly to avoid issues down the line. While I was at it, I added a get_displayable_parameters which is what I was really after that resolves which processor type to use. I think this is pretty clean and straightforward, but I wanted a PR so it is seen at the very least.

Slightly related and possibly a candidate to fold into this: DataSet.datasource. I honestly did not know we had that. It is essentially the type again but only exists if the DataSet is also a datasource. It does not appear extensively used.